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Abstract. Recently security researchers have started to look into au¬ 
tomated generation of attack trees from socio-technical system models. 
The obvious next step in this trend of automated risk analysis is au¬ 
tomating the selection of security controls to treat the detected threats. 
However, the existing socio-technical models are too abstract to repre¬ 
sent all security controls recommended by practitioners and standards. 
In this paper we propose an attack-defence model, consisting of a set of 
attack-defence bundles, to be generated and maintained with the socio- 
technical model. The attack-defence bundles can be used to synthesise 
attack-defence trees directly from the model to offer basic attack-defence 
analysis, but also they can be used to select and maintain the security 
controls that cannot be handled by the model itself. 

Full version of this paper has appeared in GraMSec 2015, to be published 
by Springer. 
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1 Introduction 

Models are used in all stages of the security process: from security require¬ 
ments elicitation and organisational risk assessment to run-time verification and 
business process compliance audit. Often these models are inter-connected. For 
example, if a security requirements model for a software system was elicited, on 
the later stage it may be re-used to design the security testing process for this 
system. At the same time, as manual production of security models is very te¬ 
dious and error-prone, many researchers and practitioners look into automating 
the model creation and transformation processes. 

Recently security researchers have looked at systematic design m and auto¬ 
mated generation of attack models 0, H, mi, [22], such as attack graphs and 
attack trees, from system models. This model transformation allows to switch 
the view from the system description perspective to a compact representation of 
possible attacker actions. At the same time, given the generated attack model, 
the system defender is interested to find the weakest links: the spots in the model 
where additional security controls can be introduced to improve protection and 


eliminate potential attacks. Therefore, automated generation of defences is an 
obvious next step in the process. 

In this paper we look at socio-technical models as succinct abstractions of 
large organisations. Such models capture simultaneously locations, actors and 
objects in the system. They often take into account both physical and digital 
domains and offer to a human analyst the means to represent “the world as it 
is”. That means that the designer of socio-technical systems does not need to 
be a security or risk analysis expert. She only needs to know the intricacies of 
her own company (department) to be able to model it. With the system model 
at hand, at the next step the attack generation tools aim at automatic creation 
of attack scenarios that can be further discussed by security professionals. The 
overall idea of this process is to automate threat scenarios identification (an 
important aspect of risk analysis) as much as possible. 

In this paper we would like to push the envelope even further. Our main ques¬ 
tion is: given a socio-technical system model, how to find and capture, possibly 
automatically, the security controls that will counteract the discovered threats? 
Indeed, the main goal of risk analysis is to improve the existing system by in¬ 
troducing new security controls, so that the most dangerous or easily executed 
attacks are thwarted. Therefore, automated creation of attack scenarios only is 
not yet a full solution. 

We want to look at perspectives and limitations of automated defence gener¬ 
ation from socio-technical models. It seems that the main obstacle to rich defen¬ 
sive strategies generation directly from the model is the fact that socio-technical 
models do not capture many security controls. 

To find an answer to the main question, we start from investigating the 
security controls (defences) already present in an advanced socio-technical model 
and propose a scheme to extract these controls, together with the attack steps, in 
the compact format of attack-defence bundles. We then evaluate the limitations 
of the extracted defences inherent from the socio-technical model and discuss 
how to overcome these limitations. We argue that an attack-defence model needs 
to be maintained (in parallel with the socio-technical model) that can capture 
not only the attacker’s view but also the defender’s view of the system. In this 
paper we have chosen attack-defence trees m as the basis for the attack-defence 
model. As an alternative to this model, one can choose, for example, attack- 
countermeasure trees |20) . 

The goal of this paper is to propose an attack-defence view for socio-technical 
models that can capture simultaneously attacker’s options and available/pro- 
posed countermeasures in the system. The main idea is that given that view it 
can be easily synchronised with the model (but it contains richer defence infor¬ 
mation than the model), and it can be used to synthesise attack-defence trees 
and evaluate different interesting attributes. 


2 Socio-Technical Models versus Attack-Defence Models 


As socio-technical models are abstractions, they do not capture all defensive 
mechanisms that can be available in an organisation, but only a subset of them. 
Indeed, it is impossible to model all security-relevant devices, protocols and 
behaviours in a single model. Typically, socio-technical models look at capturing 
organisational infrastructure (e.g., [10], [16], [18], [12]), but sometimes they can 
focus only on some aspects of human-computer interactions (e.g., [19], i)- 

Since all security aspects cannot be captured by a socio-technical model 
without overcomplicating it, we argue that there is a need to maintain a separate 
view of attack and defence capabilities of the system together with the socio- 
technical model. Preferably, we should be able to trace the objects in the socio- 
technical model into the attack-defence model and back. 

Requirements for the attack-defence model 

The first requirement for the chosen attack-defence model is that the defences 
that are already captured by the model need to he represented explicitly in the 
attack-defence model. Indeed, we would like to faithfully represent the system 
security state. So, if some security control is captured by the system model, it 
should be translated into the generated attack-defence model. 

Secondly, we want to propose a way to update the generated defender’s view 
(the security controls obtained directly from the system model) with more secu¬ 
rity controls and countermeasures of the organisation. This update needs to be 
consistent: once a security control is captured in the attack-defence model, it 
should be traced to an object in the system model. For example, if our approach 
identifies that a security camera is to be placed in a certain location in the sys¬ 
tem, all attack scenarios that involve that location should be updated to take 
the camera into account. In this way later on one can investigate automated 
defence generation process that will maintain consistency of the socio-technical 
system. 

Background 

In this paper we use the TREsPASS socio-technical model m that is graph- 
based. We can briefly summarise this model as follows. Locations in the system 
represent physical and network locations; actors model humans and processes; 
and items can be physical or digital objects. Edges among locations represent 
connectedness (e.g., adjacent rooms), and all actors and items are located some¬ 
where in the system. Actors can possess items, and items can be embedded 
into other items. Some locations have access control policies attached to them. 
These policies specify a set of credentials (items in the system) an actor needs 
to possess to enter the location or access the object. These policies can also be 
formalized by more complex predicates capturing, e.g., role-based access control 
or trust relationships among actors. 

As the starting point for the attack-defence model, we consider the process 
of attack trees generation by policy invalidation that relies on structural in¬ 
formation about the system M. m. i- This process was initially designed for 
the TREsPASS socio-technical model [10], but it can be applied to other socio- 


technical models capturing systems as graphs, e.g., [18], [16], 0, m. because 
it is reachability-based. 

In short, this process is started by choosing an asset among the entities in 
the system. The attacker is also selected among actors in the system (the main 
goal of the attacker is to invalidate the security policy, e.g., confidentiality or 
integrity policy, associated with this asset). Then, based on the reachability 
reasoning, the process systematically searches for the ways for the attacker to 
access the asset. For example, consider the asset to be a sensitive document 
located in a locker in the manager’s office, and the attacker to be an insider (an 
employee) working on the same floor. To access the document, the attacker can 
try to access the locker and open it (an AND-decomposition my This might 
require possession of the key to the locker that needs to be obtained elsewhere in 
the system. Alternatively (an OR-decomposition with the previous attack), also 
the manager has access to the locker and the document. Thus, the attacker can 
get access the document by influencing the manager. This can be implemented 
through, e.g, social engineering (for instance, befriending the manager, or hiring 
an external actor to pretend to be a higher executive who needs the document), 
bribing, or coercing the manager. 

In this small motivating example we see that two general attack strategies 
come into play: the attacker can actively pursue moving across the system and 
collecting items that will open him the way to the desired asset, or the attacker 
can attempt to orchestrate actions of other actors in the model so that they will 
do the necessary actions for him. Irrespectively of the chosen strategy, the pro¬ 
cess of attack trees generation by policy invalidation will systematically identify 
available (reachable) steps, add them to the tree, and refine those steps further, 
producing a complete attack tree in the end [5]. Notice, that this summary is a 
simplification of the overall process, and we encourage the reader to refer to the 
original articles about the approach for more details i, m, i- 

3 Attack-Defence Model 

Extraction of defences from the model 

The only security controls the TREsPASS socio-technical model captures are 
access control policies that restrict access to certain locations. These policies 
can correspond to physical (locks) or digital (password check) means (policy 
enforcement mechanisms) implemented in the system to restrict access to assets. 
Therefore, we propose to make explicit in the attack generation process the fact 
that the attacker needs to overcome the restrictions imposed by security policies. 
To achieve that we will use attack-defence bundles that are based on the attack- 
defence tree formalism m- 

Intuitively, the attacker can chose from two approaches to deal with secu¬ 
rity policies in the system. He can attempt to satisfy the access control policy 
(for example, by collecting the necessary credentials or coercing someone with 
the right credentials) or he can try to circumvent the policy (e.g., by forcing the 
lock). The first approach is in line with the attack tree generation by policy inval- 


idation process, because it can be automatically designed based on reachability. 
If we want to refine the second approach, we need to understand how exactly 
different policies (more precisely - enforcement mechanisms for these policies) 
can be circumvented. There is a need to represent the human expert knowledge 
in circumventing different security mechanism in such a way that it is useful for 
automated generation process. To achieve that, one can use, for example, the 
hierarchical approach to attack representation suggested in m- 

Indeed, the enforcement mechanisms for access control policies defined in 
the socio-technical model can be automatically introduced into attack-defence 
trees. If the knowledge about breaking certain kinds of enforcement mechanisms 
is available in a suitable format (e.g., the hierarchical representation), then the 
attack-defence trees can be further refined based on that information. Further 
analysis based on the attack-defence trees produced at this stage (e.g., compu¬ 
tation of the most probable or the most cheap attack for the attacker 0) can 
identify the missing enforcement mechanisms. For example, if in the sensitive 
document scenario the attacker can directly access the document because the 
locker does not require any key (no access control is enforced for the document), 
it might be the first recommendation for improving security of the organisation: 
to introduce some appropriate access control mechanism (e.g., an actual lock 
with the key) to protect access to the document. 

3.1 Simplified Socio-Technical Model 

We introduce a simplified TREsPASS socio-technical model to exemplify the 
attack-defence model creation. The simplified model allows to reason only about 
potential reachability. However, this is already very useful for risk analysis, as 
quantitative evaluation of the possibility that an attacker accesses some system 
elements can simplify risk analysis for human analysts [13) . 

The simplified model captures simultaneously organisation’s infrastructure 
topology for both physical and digital locations, as well as actors moving around 
this infrastructure (these can be persons or processes). In the model these en¬ 
tities are represented as a set of model elements N that is a union of a set of 
infrastructure locations Ni, actors Na, and objects No- We consider two do¬ 
mains: Ph is the physical space (model elements in this domain are physical 
entities, including, e.g. rooms, persons, and items), while Dg is the digital space 
(network locations and processes are in this domain), such that N = Ph U Dg^ 
and Ph n Dg = 0. 

Some model elements are connected. We denote a.s E C N x N the set of 
directed connections. All edges e in E are of the following types: 

— e G Eii C NiX Ni'. connections between infrastructure locations (rooms, cor¬ 
ridors, etc.). These connections are assumed bi-directional. More precisely, 
if (A,* 2 ) G Eli then (^ 2 , 11 ) G 

— e G Eai C Na X Ni'. placement of actors in the infrastructure; 

— e G Eoi C No X Ni'. placement of objects in the infrastructure; 

— e G Eoa C A^o X Na'. placement of objects that are carried around by actors; 


— e G Eoo Q No X No', placement of objects that are inside other objects; here 

e = (oi, 02 ) denotes an object 0 i located within an object 02 . 

Mutual intersections of Ea, Eai, Eoi, Eoa, Eoo are empty sets. Elements of the 
same domain can be connected liberally. However, some self-evident restrictions 
apply when connections between elements of the physical and digital domains 
are considered. For example, a data file cannot be located in an office or inside 
a cupboard. We allow multiple locations for the same actor and object. This 
corresponds to the possibility of actors to move in the model, and represents 
that some items can appear in several locations. 

We define a location function loc(): N x N as follows: Vn G N loc(n): = 
{I G N\{nJ) G E}. 

Notice that for infrastructure locations or actors the function loc() returns 
infrastructure locations where these model items are accessible from. However, 
as objects can be accessible from actors or other objects, loc() may return any 
type of items in the model. 

Policies 

Let P be a set of policies defined in the model. We consider access control 
policies represented as tuples restricting access to element n. The local policy S„ is 
a set of individual access control configurations. Each access control configuration 
p G is a tuple {Cred, atLocation, EM), where Cred C TVq is a set of credentials 
required to get access, atLocation G N s.t. (n, atLocation) G E is a model 
element from which access to n is granted (e.g. access from the office to the 
locker is granted with the key in the example in Sec. [^, and EM G fV is a 
reference to the mechanism enabled in the model to enforce the policy. EM 
can be the same as atLocation, meaning that the enforcement mechanism is 
implemented right at the spot (e.g., a lock), it can be an actor (e.g., a security 
guard checking identity documents or a process implementing access control), or 
an object. Notice that we assume that c G Cred C No is an asset present in the 
model, which can be either an item or data. 

In theory, different access control configurations of the same local policy 5n 
can be enforced by different enforcement mechanisms. For example, to access a 
building employees might use a badge applying it to an RFID-reader, or they 
might show their IDs to a security guard. 


3.2 AD-Bundles Generation 

We will now show how to generate attack-defence bundles (AD-bundles) that 
can be used to capture the attack-defence state of the system. AD-bundles are 
generated for individual assets. They consist of attack nodes that correspond to 
gaining access to items in the model and attacking these items, and defence nodes 
that represent protections offered by the local policies in place. Notice that the 
bundles are attacker-agnostic, and they refer only to the system configuration 
regarding some particular item. Our notation abuses the standard notation for 
attack-defence trees, as we use AD-terms to represent both the tree structure 


and to refer to concrete attacker goals. We also define different types of AD- 
terms. This is syntactic sugar to ease the type representation, as types are used 
to put bundles together and synthesise AD-trees. 

Attack node types. We consider attack nodes can be of the following types. 

— accessn is an attack node that represents that the attacker gains access to 
item n. 

— access-frorriny represents the goal of the attacker to access item n from 
specific model element 1. This node type explicitly states the way n is ac¬ 
cessed in the model, thus allowing us to understand immediately what access 
control policy is applicable (by looking at the atLocation attribute). 

— breakn represents the goal of the attacker to somehow disable an access con¬ 
trol mechanism implemented in n (this enforcement mechanism can protect 
assets not located in n). 

— attackjpolp represents the goal of the attacker to overcome protection of an 
individual access control configuration p. 

— satjpolp represents attacker’s goal to satisfy access control configuration p 
(by collecting all necessary credentials). 

Defence node types. The defence nodes can be of the following types: 

— EMnj represents the defence of enforcement mechanisms enforcing policies 
at I to control access to n (notice that the enforcement mechanism itself can 
be located elsewhere). 

— poDconfipp represents protection offered by an individual access control con¬ 
figuration for some p € Sn- 

Notice that term types attack_pol and poDconfig are required to satisfy the 
requirement of AD trees for the unique child of the opposite type El- 

Bundle construction. Let n G be an item in the model. An AD-bundle Bn 
that characterises accessing n is constructed as follows. 

We start by setting the root of the bundle to accesSn, as this is the desired 
attacker’s goal. 

Next, accesSn is refined: 

accesSn ■= (^access-fromn,i\l € loc(n)^ // n can be accessed only from an 
adjacent element in the model. Any of these elements is suitable for the attacker 

If fip = {Cred, I, EM) e i5„ then 

access-fromn,i '■= accessi // access to n from I can be implemented by simply 
accessing 1. No access control policy is set up to guard this connection. 

If 3p = {Cred, I, EM) G d„ then 

access-fromn,i := c^ (^accessi, EMny'^ // access to n from I can be imple¬ 
mented by accessing 1. However, as there is an enforcement mechanism that 


controls access, the defence node is also added. 


EMn,i '■= A° {^poLconfigpiyp G s.t. p = (Cred, I, s}J j j Protection of 

access from I to n is implemented via individual policy configurations. 

poPconfigp := c^ (^attack_polp^ // syntactic sugar to switch back to at¬ 
tacker’s view 

attack.polp := (^sat-polp, breaks'^ , where p = {Cred, l,s) j j Attacker can 
either satisfy the individual policy configuration p, or he can break the enforce¬ 
ment mechanism s that enforces this configuration p. 


satjpolp := A'P (^accesscredl'^cred G Cred'j, where p = {Cred,I, s) j j To 
satisfy the configuration the attacker needs to access all credentials in the set 
Cred identified in this configuration. 


We provide an example of an AD bundle in Fig. [l] By construction, for 
each bundle Bn its leaf nodes are either terms of the same type (access; for 
some 1), or terms breaks. We do not refine terms of the type breaks because the 
model itself lacks the knowledge how enforcement mechanisms can be broken. If 
an additional knowledge on breaking enforcement mechanisms will be available 
(e.g., as a hierarchy of attacks m), this term can further expanded. 




Fig. 1. An AD bundle. 






























3.3 Approach to Synthesise AD-Trees 

AD-bundles represent attacks on individual assets in the model. They can be 
“glued” together to form AD-trees, in the spirit of attack generation by policy 
invalidation. In this subsection we outline an approach to synthesis of attack- 
defence trees. 

The main requirement for AD-trees synthesis is that it should terminate. 

Indeed, it is easy to see that any simple loop in the infrastructure will create in¬ 
finite trees if bundles are composed naively. Moreover, some bundles may appear 
more than once in the generated tree, creating duplicate subtrees. To avoid this, 
we introduce a system state that will keep track of already achieved progress 
and will allow to terminate the synthesis process when the attacker has achieved 
the goal. 

State. We define now two functions that identify the state of the system. These 
functions will be updated as the attack tree is generated in order to keep track 
with the attack development. 

Definition 1 (Reachable(,)). Let M = {N, E) he a model. We define a boolean 
function Reachab Ie{,) C Na x N: 

— If{a,n) G E, Reachable{a,n) := True. 

— If for some I € Ni {a,l) € Eat and {o,l) € E^, then Reachable{a,o) := 

True. 

— If for some I € Ni {a,l) G Eai and {ai,l) G Eai, then Reachable{a,ai) := 

True and Reachable{ai,a) := True. 

— Else Reachable{a,n) := False. 

This function initially captures for a given actor all items immediately reach¬ 
able in the model. These items can be objects or actors located in the same 
location as the actor. Let Reach(a) := {Vn G N s.t. Reachable(a, n) = True}. 

Definition 2 (Granted(,)). We define a boolean function Grantedf) C Na x 
N: 

— If for an item n Sn = 9 then Granted{a,n) := True. 

— If for an item n there is a tuple p = {Cred, atLocation) G Sn = s.t. Cred C 
Reach{a) n No then Granted{a,n) := True. 

— Else Granted{a,n) := False. 

Intuitively, this function refers to some policy configuration that grants access 
to n. If Granted(a,n) = True, then there is a way for this actor to satisfy the 
access control policy for n (possibly under condition that he arrives at the right 
location). 

Let us define a model state. 

Definition 3 {Stsite). A generated state for a model M is a tuple {Reachable^,), Granted^,)). 

Definition 4 (Accessible),)). We define a boolean function Accessible{,) C 
Na X N: 

— Accessible(a,n) := Reachable(a,n) A Granted{a,n) 



Bootstrapping Given a model A4= {N, E) produced by a modeller, the functions 
Reachable(,), Grcinted(,) and Accessible(,) are initially computed from Ai. 
First we compute a transitive closure of reachable locations: 

— Reachable(a, n) := Reachable(a, n) V {31 S N : Accessible(a, Z) A((Z,n) € 
E V{n,l) G E) ) 

Notice that here we do not re-compute the function Grcinted(,), and thus, even¬ 
tually, the reachable objects set for each actor will increase only with locations 
that are not guarded by access control policy. Once Reachable(,) is recomputed, 
it can be used to quickly evaluate whether an actor can reach certain locations 
in the original model (where may he end up). 


Synthesis of AD-trees from Bundles We now discuss composition of gen¬ 
erated attack-defence trees. An attack-defence tree ADT)/^, a) is synthesised for a 
chosen attacker r] G Na and a target asset a £ No- The root node is the bundle 
accessa- For each leaf node of the type accessb we can compute its value by 
referring to the corresponding AD bundle Bb- 

Bundle Value. In the simplest case we use propositional semantics for evaluating 
AD-bundles and, eventually, AD-trees m- For leaf nodes of the type access^ 
accessn = Access±hle{r],n). For leaf nodes of the type breaks, breaks = False 
in the current synthesis approach. Thus, given a bundle for asset n, we can 
evaluate its value based on the values of the leaf nodes available. By updating the 
model state as attack progresses (more items become reachable to the attacker) 
we can eventually evaluate the target bundle, once all its descendants become 
evaluated. As state changes monotonically, the process will eventually terminate. 

4 Introducing New Defences 

The enforcement mechanisms for access control policies are not the only type 
of security controls that organisations use. Moreover, access control is not the 
only remedy that can be advised to improve security. Indeed, the existing risk 
analysis standards and security catalogues that guide practitioners in risk analy¬ 
sis identify many types of security controls and countermeasures. Many of those 
(for example, security cameras) cannot be captured by socio-technical models 
directly, because it will introduce unnecessary complications to the model. Some 
countermeasures can be introduced as properties of system elements (e.g., af¬ 
ter a security training the employees might become less susceptible to social¬ 
engineering), but not as independent elements of the system. 

We want to be able to update the attack-defence model of our system, cap¬ 
tured by the suite of attack-defence bundles, after the first stage of automated 
generation. At this second stage we would like to obtain more complete attack- 
defence bundles with new defence nodes added that can capture additional se¬ 
curity countermeasures (either existing in the model already or newly proposed 


once). We have two main questions associated with the newly introduced de¬ 
fences: how to generate/propose new defences and where to place them in the 
attack-defence model to keep the consistency across many attack scenarios and 
system updates. We start by addressing the second question first. 

Where to put new countermeasures 
Given an AD bundle representing the goal of an attacker to access asset n, two 
types of attack nodes are the candidates to be protected from by some coun¬ 
termeasures: the root node accessn and its children access-fromn,i- Indeed, for 
the connectors to other bundles (the leaf nodes accessf) it will make sense to 
introduce defences at the corresponding bundle to ensure the consistency re¬ 
quirement. For the nodes satjpolp, the attacker’s goal is to satisfy the policy 
by finding the right credentials. It is not obvious what can be done as a pro¬ 
tective measure besides protecting the credentials themselves. As for the nodes 
representing circumventing the enforcement mechanism, breaks, we do not have 
enough details for the moment how the attacker is going to break it. If this node 
is to be refined using some attack pattern library, it is better to create a separate 
AD bundle for treating the scenarios and assign defences there. 

Now we have candidate attack nodes to be assigned countermeasures. To 
select the countermeasures that could be assigned, we first review existing types 
of security controls. It is well-established in the security industry to classify 
controls as preventive, detective and corrective [T]: 

— Preventive controls focus on preventing security incidents from occurring. 

~ Detective controls focus on detecting occurrences of security incidents. 

— Corrective controls focus on aiding the organisation to recover from a security 
incident. 

From the implementation perspective, it is traditional to divide controls into 
the following categories [T]: 

— Technical controls that are implemented typically as software controls. 

— Management, or administrative, controls that are implemented as procedures 
and guidelines. 

— Operational controls that focus on ensuring security and dependability of 
operations. These controls include physical security controls (physical access 
control, fire and water damage protection, etc.) and some controls that are 
difficult to classify as fully technical or physical (e.g., protection of personal 
computers). 

From this classification, we propose a way to update AD bundles with secu¬ 
rity controls in a consistent manner. The preventive controls can be added as 
children to the attack nodes access-fromn^i, because they correspond to preven¬ 
tive measures for certain directed actions of the attacker. Access control policies 
present in the model are already embedded in the bundles at this position. To 
satisfy the at tack-defence trees requirement of only one child of the opposite 
type, we will modify the bundle as in Fig. (now the node is a parent 

of the node EMn,i)- 



Fig. 2. An updated AD bundle with defence nodes in the designated positions (children 
of EM(n,/) not shown). 


The detective and corrective measures can be added as children to the root 
node accessn (see Fig. [^. In this position the defence nodes are directly linked 
to the system object in question, be it a location, a person, or an object. The 
semantics of the controls placed in this position are clear: assuming the attacker 
has already gained access to his target, is this detectable or what can be the 
remedy for this? Notice that some controls in practice can be both detective 
and preventive (e.g., security guards). In this case, it is safe to classify them as 
preventive controls. 

What defences to choose 

The choice of security controls is a tough question in practice. Not only it requires 
the human analyst to know possible attacks and countermeasures, but also the 
analyst needs to solve a complex multi-parameter optimisation problem. Indeed, 
the controls addressing the same threat can have different cost, efficiency and 
effectiveness. They can be more or less compliant with the industry standards 
and best practices. They can be more or less easy to implement and easy to 
verify. Finally, they can be more or less desired by the organisation because of 
personal views of the top-management. Thus, if we just consider the baseline 
controls listed by NIST Special Publication 800-53 [2], and try to evaluate all 
the above-mentioned parameters in order to fully automate the defence selection 
(now that we know where to place them), we already will face a very complex 
problem. Moreover, a single mistake in evaluation of some of the values will likely 
make the full analysis invalid. Therefore, it is likely that human-assisted control 
selection cannot be fully replaced by automated defence generation, at least for 
some time. 

Yet, we can try to facilitate the defence selection problem by further cate¬ 
gorising the security controls based on applicability to the scenarios in question 
and usefulness in attribute-based computations. 

In the socio-technical model we have clear categories of objects: locations, 
actors and items that can belong to either physical or digital space. Thus controls 
can be chosen based already on simple considerations such as “access to digital 














Table 1. Controls selection based on system elements. 


Entity | Physical space | Digital space 

Preventive 

Location 

Physical access control 

Technical access control, firewall 

Actor 

Physical access control, Security trainings, Email filter 

Technical access control and authentication 

Object 

Physical access control 

Technical access control 

Detective 

Location 

Actor 

Object 

Security cameras, visitor logs 

System logs, IDS 

Corrective 

Location 

Actor 

Object 

Insurance, liability limitation, 
business continuity plan 

Insurance, liability limitation, 
secure state restoring mechanisms, 
business continuity plan 


Table 2. Relevant controls for example attributes 


Attribute 

Preventive 

Detective 

Corrective 

Risk of detection 




Cost of attack (for attacker) 

V 



Probability of attack success 




Time of attack 




Impact of attack 



V 


objects by processes can be protected by using technical preventive controls”, or 
“access of humans to humans can be protected by administrative and physical 
preventive controls”. Table [l] summarises these choices of controls. In this table, 
it is expected that respective controls will be introduced in the dedicated AD 
bundles (following the template in Fig. [^. 

Furthermore, following the investigation of attribute decoration on attack- 
defence trees by Bagnato et al. [3], we can look at what controls contribute 
to computations of certain attributes. For instance, if the analyst is interested 
in the probability of an attack to succeed, the minimal cost of attack for an 
attacker, or time of executing an attack, then (under the assumption that detec¬ 
tion cannot stop the attack) she would like to look at her preventive measures. If 
she is interested in the impact the attack has on her organisation (how business 
continuity is affected after the attack was executed), she would like to consider 
the preventive and corrective controls, especially the latter ones, because these 
ensure business continuity. Thus, if she is interested only in some attributes, the 
computation on AD bundles does not need to take into account all controls at 
once. Table summarises the control types that are the most relevant for some 
selected attributes. 

Notice that the controls added at this stage will probably not follow the AD 
bundle notation, but will be expressed in the natural language (e.g, security 
training or ID check). This is understandable, because, as we have mentioned, 
models are not rich enough by nature. Yet, this is acceptable for the format, be¬ 
cause the attack-defence model does not need to be fully formal. On the contrary, 
it is used to assist the human analyst to create and maintain the attack-defence 
view on the system. The only requirement that we have for it is the consistency. 



























which is ensured by adding each control only to the bundle representing the 
attack-defence view of a particular (unique) entity in the model. Some controls 
can require a notion of perimeter to be defined in the model, so that they can 
be uniquely assigned to the bundle corresponding to the perimeter, and not to 
each entity belonging to that perimeter. This is easily implementable in any 
socio-technical model. 

5 Related Work 

The question of attack trees generation from system models has been tackled in 
[g. Similarly, [22] and [T2| worked on generating attack models from a system 
model. While we follow the same approach for attacker’s view, our main focus 
is on keeping both attacker’s and defender’s views consistent with the main 
socio-technical model. 

Attack-countermeasure trees (ACTs) is an alternative model to at tack-defence 
trees in keeping both views simultaneously |20] . In m the authors have inves¬ 
tigated optimal countermeasure selection for ACTs when a set of possible coun¬ 
termeasures to be implemented is already predefined. It will be interesting to 
investigate ACTs suitability for the attack-defence model, because they support 
explicit detection and mitigation countermeasure nodes (but not corrective). 

In [T2| the authors work on directly applying model checking to a socio- 
technical model in order to evaluate some reachability-based security properties. 

Ferreira et al. [6] have discussed defences suggestion in the context of the 
socio-technical model STEAL. They propose to apply defences at the technical 
and social levels of the system, what is in line with our proposal for applying 
security control categories in selecting defences. 

6 Conclusion and the Next Steps 

In this work we have approached the question of creating and maintaining the 
security controls representation in parallel to the socio-technical model. Our 
solution creates a set of attack-defence bundles (small attack-defence trees) that 
can be maintained with a socio-technical model as its separate view. The bundles 
are generated from the model in the beginning, but afterwards they are enriched 
consistently alongside the new security controls identified by a human analyst. 
We have also discussed how new controls can be selected based on the model 
entities and the attributes of interest to the analyst. This work attempts to bridge 
the gap between the approach of automated attack generation from system model 
and the manual security control selection in the traditional risk analysis. The 
next step is to look into the compositional attack-defence tree synthesis for more 
complex attribute domains. After that, it will be possible to investigate optimal 
countermeasure selection, based, e.g., on the approaches suggested in |g and 
|2I]. Another further research direction is practical validation of the proposed 
approach on realistic case studies and evaluation of its usefulness and scalability. 
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